Subject: SSP Header Shortcoming

From: Frank Bordonaro <[email-masked]>
Date: Mon, 14 Mar 94 18:19:44 PST

I would like to point out a shortcoming of the current SSP header 
and propose a solution. I realize that it is late in the game, but 
I think a little pain now may be worth saving bigger pain later.

The main problem is that the SSP Message Type field is overloaded.
It explicitly calls out the message type and implies the message 
length based on the type. The problem arises when new message types
are defined and a new message type is sent to a dlsw peer that 
does not recognize the new message type. The peer receiving the new 
message will not recognize it and must guess at it's SSP header length.
If it guesses incorrectly, it will never get back in synchronization 
to read the next SSP header.

Since the standard is still evolving and most likely will continue 
to evolve for some time, it seems very likely that new message types 
will be defined. There are several ways to avoid the loss of SSP header
alignment and subsequent tearing down of the TCP session.

The first is that for all SSP message types not recognized, the receiver
could assume a certain size (probably 72 bytes). Although this is a 
viable option, it limits the kinds of SSP header improvements we could
make, namely reducing the size of the header for control messages.

The second option is to add a new SSP header field to both control and
information headers called Message Header Length. This would allow 
unrecognized SSP messages to be discarded and the next SSP header to
be read without difficulty.

I would propose that we chose adding the Message Header Length field 
because it allows for creative and optimal use of SSP headers as we 
learn. If we are defining a standard that will live for any period of
time, this gives us some flexibility.

Frank Bordonaro           
[email-masked]
cisco Systems, Inc.

---

From: "Steve Klein" <[email-masked]>
Date: Thu, 7 Apr 94 07:40:18 EDT

Reference: Note from Frank Bordonaro dated Wed, 30 Mar 94 19:41:54 PST

Frank, backwards compatibility is a concern for me also.  That is why I
think it would be prudent to leave the SSP message type and header length
fields were they are in RFC 1434.  This would allow a 'standard DLSw'
from any vendor to be introduced into a RFC 1434 DLSw network without
the customer having to replace all the routers at once.  Moving the SSP
message type and header fields mean an 'all or nothing' migration path
for customers implementing the 'standard DLSw'.

Steve

------------------------------- Referenced Note ---------------------------
>Received: from glare.cisco.com by vnet.IBM.COM (IBM VM SMTP V2R2) with TCP;
>   Wed, 30 Mar 94 22:41:07 EST
>Received: (fbordona@localhost) by glare.cisco.com (8.6.8/8.6.5) id TAA12938; Wed, 30 Mar 1994 19:41:55 -0800
>From: Frank Bordonaro <[email-masked]>
>Message-Id: <[email-masked]>
>Subject: Re: SSP Header Shortcoming
>To: [email-masked] (Steve Klein)
>Date: Wed, 30 Mar 94 19:41:54 PST
>Cc: [email-masked]
>In-Reply-To: <[email-masked]>; from "Steve Klein" at Mar 24, 94 10:03 am
>X-Mailer: ELM [version 2.3 PL11]
>
>Steve,
>
>  As I re-read my original note, I see I did not express my thought
>  as clearly as I would have liked. Let me try again.
>
>  As long as the "new" SSP formats are at least 20 bytes in length
>  and include the existing Header Length field at the same offset as
>  the Control Message header, we will have no trouble creating new
>  formats. My point is that the above restiction is totally unnecesary.
>  For the flexibility to be creative and reduce the SSP header in size
>  to something less than 20 bytes, *all* SSP messages should start with
>  the Header Length followed by the Message (data) Length and then followed
>  by the Message Type. This does not tie our hands in any way for future
>  SSP message formats. If an SSP receiver does not recognize the Message
>  type, it knows the header and message (data) length and can find the
>  start of the next frame in the TCP pipe.
>
>  From my experience, backwards compatibility is the biggest problem
>  as a product evolves. The better job we can do up front to make
>  it easier for the product to grow/change, the better off we will be.
>
>  My intent is to bring this to your attention. If it makes sense to
>  other vendors as it does to us, then we should consider a change. If
>  not, we will all have to handle backward compatibility in our own way.
>
>Regards,
>Frank Bordonaro
>